home *** CD-ROM | disk | FTP | other *** search
/ Windows Expert / Windows Expert.iso / windownt / pterm.zip / readme.now < prev   
Text File  |  1993-06-17  |  31KB  |  656 lines

  1.  
  2.  
  3.  
  4.                                   P T E R M
  5.  
  6.                          Paragon Terminal Application
  7.  
  8.                                 for Windows NT
  9.  
  10.                                  Version 0.1b
  11.  
  12.                                 18, June 1993
  13.  
  14.  
  15.  
  16.  
  17.    What's Going on Here?
  18.    =====================
  19.  
  20.       This is a beta of Paragon Terminal Application for Windows NT. What's
  21.       so great about PTERM? Not much yet, but here is a list of features
  22.       available so far:
  23.  
  24.          o  Fully threaded (6 so far), native Win32 application
  25.  
  26.          o  Auto Zmodem download/upload
  27.  
  28.          o  Fast ANSI (including color!) terminal emulation
  29.  
  30.          o  Console based for speed
  31.  
  32.       The other valuable feature of PTERM is that as far as I know it is
  33.       the only Zmodem capable native, multi-threaded Win32 terminal
  34.       application available. It won't be for long, but for now...
  35.  
  36.       Some glaring omissions:
  37.  
  38.          o  No Dialer!?!?!
  39.  
  40.          o  No user interface driven configuration
  41.  
  42.          o  No annoying "register me now, or die" messages and
  43.             purposefully broken features.
  44.  
  45.          o  Many other things which you will likely go insane without (but
  46.             hang in there, it is my intention to evolve PTERM).
  47.  
  48.  
  49.    Why Would You Do Such a Thing?
  50.    ==============================
  51.  
  52.       Some months back, I was asked to beta test a C++ based,
  53.       multi-platform communications library from a company called Lookout
  54.       Mountain Software (William Herrera, owner/author, BBS 719-545-8572).
  55.  
  56.       The best method I could think of for testing this package was to use
  57.       it as the core of a terminal application -- and PTERM was born.
  58.  
  59.       William has been extremely sensitive to the problems I found and
  60.       enhancements I suggested, and should be commended for authoring such
  61.       a stable and comprehensive communications library, which is available
  62.       for DOS, Windows, OS/2 and Windows NT. All of the file transfer
  63.       protocol code (Zmodem/Ymodem/Xmodem) is Williams, and he has done an
  64.       excellent job implementing them (sealink and telink are also included
  65.       in the communications library, but not in PTERM -- Xmodem and Ymodem
  66.       will be available in the next release of PTERM).
  67.  
  68.  
  69.    I Didn't Do It, I Swear!
  70.    ========================
  71.  
  72.       Every precaution has been taken to ensure the safe operation of PTERM
  73.       in your Windows NT system. But, come'on, not only is this copy of
  74.       PTERM in beta, but so is the current (March '93) build of NT, so
  75.       obviously I cannot be held responsible for any damage done to your
  76.       system (or psyche) by PTERM or any interaction involving PTERM. So
  77.       all I can say is "I didn't do it!", so don't blame me!
  78.  
  79.  
  80.    What Do I Need To Use Pterm?
  81.    ============================
  82.  
  83.       You need an Intel based (Intel Inside sticker optional) PC running
  84.       Windows NT (March '93 build or later), with at least one serial port
  85.       and a modem attached to that port.
  86.  
  87.       If someone would like to send me a MIPS R4400 or DEC Alpha AXP, I
  88.       will be glad to get PTERM up on those platforms as well <grin>.
  89.  
  90.  
  91.    Alright, What Do You Want For This?
  92.    ===================================
  93.  
  94.       The list of things I want would be much too large to include in this
  95.       document, so you will have to settle for what I need.
  96.  
  97.       What I need, from you, is the following:
  98.  
  99.          o  Bug reports (there should be plenty)
  100.          o  Suggestions (again, no shortage expected here either)
  101.  
  102.       So, please, please inundate me with this information, I promise I
  103.       will consider anything submitted (but nothing not submitted).
  104.  
  105.       I can be reached via internet mail at:
  106.  
  107.          roncox@indirect.com
  108.  
  109.       FIDOnet people, try netmail to UUCP at 1:1/31, first line of the
  110.       message body:
  111.  
  112.          To: roncox@indirect.com
  113.  
  114.       I plan on finding a reliable FIDOnet system here in town, and when I
  115.       do I will post my FIDOnet address for netmail.
  116.  
  117.       For slowest response, choose snail-mail:
  118.  
  119.          Ron Cox
  120.          Paragon Consulting Group
  121.          4212 West Cactus STE 1110-229
  122.          Phoenix, AZ  85029
  123.          ATTN: PTERM
  124.  
  125.  
  126.       If you are a Windows NT developer, and would like to contribute code
  127.       to PTERM, let me know! Currently I have no plans to charge real money
  128.       for PTERM, so you will get the same thing I do as far as that goes,
  129.       nothing but recognition (we'll be lucky to get that!). Any code you
  130.       contribute will become public domain, and may be distributed in the
  131.       future (in source or object form) or used in other projects without
  132.       restriction.
  133.  
  134.  
  135.    Free? Something Must Be Broken!
  136.    ================================
  137.  
  138.       Actually, yes. I am releasing this with a several known bugs, and I'm
  139.       sure many more unknown bugs. I am of the belief that the bugs I know
  140.       about will not significantly affect the operation. Some require bug
  141.       fixes in NT or the SDK, others just require me to figure out what's
  142.       going on. Here is a list of the bugs I know about:
  143.  
  144.          o  The first time (during a given run) an upload starts and the
  145.             file selection dialog pops up, it does so behind the console
  146.             window PTERM is running in. After the first time, and during the
  147.             same run, the file selection dialog will pop up above the PTERM
  148.             window as expected. I am working on getting this fixed.
  149.  
  150.          o  After each file of a Zmodem upload, there is a 15-20 second
  151.             period where a sync with the host is attempted. During this
  152.             period, there are usually several (3-5) timeout messages. The
  153.             sync finally takes place, and the host usually accepts the
  154.             transfer. This is irritating, and throws off the CPS rating,
  155.             but seems to cause no other problems. I am working on getting
  156.             this problem solved more than any other.
  157.  
  158.          o  Occasionally, when exiting PTERM, just before the console
  159.             window goes away, you may see a brief message mentioning some
  160.             runtime error. I have no idea what is causing this, but am
  161.             investigating it. I tend to believe it is a problem in the
  162.             current build of the NT runtime libraries. It does not seem to
  163.             have any adverse side effects.
  164.  
  165.          o  As mentioned, PTERM supports ANSI terminal emulation.
  166.             However, I was unable to find any definitive document on
  167.             ANSI, so I am sure some sequences are not supported, and
  168.             its possible ones I do support operate incorrectly. I have
  169.             little or no problems with the BBS's I call (including a UNIX
  170.             shell account with ansi emulation) around town. I believe that
  171.             ANSI is a superset of VT-100/102, so PTERM may work with
  172.             these emulations as well. If anyone has a detailed document on
  173.             ANSI/VT-100/VT-102, please, please send it to me. It needs
  174.             to be real detailed and complete (I already have various bits
  175.             and pieces). Also, the emulation in PTERM is tuned for 9600 baud
  176.             and higher, so you guys with the old 1200 and 2400 baud modems
  177.             will notice that PTERM spits out blocks of characters, giving
  178.             the output a somewhat jerky appearance. This can be minimized by
  179.             having PTERM use the actual baud rate you expect to connect at
  180.             (see configuration below).
  181.  
  182.          o  When PTERM is run in a console window without a scroll bar,
  183.             characters in the last column do not always scroll. I believe
  184.             this to be a bug in NT, but am investigating. In any case, the
  185.             solution is simple, use the system menu/buffer size to change
  186.             the lines in the buffer to be larger than the size of the
  187.             window PTERM is running in, which adds a scrollbar to the
  188.             window. Actually, this is convenient as it gives you a scroll
  189.             back buffer. I typically run PTERM in a window whose buffer is
  190.             1024 lines (although the window size is 80x25), giving me that
  191.             much scroll back.
  192.  
  193.       Well, them's the major ones I have found so far. Please report others
  194.       to me as necessary.
  195.  
  196.  
  197.       Some 'features' to watch out for:
  198.  
  199.          o  Once PTERM quits, it closes the serial port, and if the modem on
  200.             this serial port is currently connected to somewhere, that
  201.             connection will be lost (since closing the serial port drops
  202.             DTR). You may be able to prevent this by setting your modem to
  203.             always hold DTR high, but this will have the side effect of
  204.             preventing ALT-H from hanging up the connection.
  205.  
  206.          o  If there exists, in your download path, a file with the same
  207.             name as one you are attempting to download, the transfer will be
  208.             aborted. I apologize for this, and I will have a reasonable
  209.             automatic rename mechanism available in the next release.
  210.  
  211.          o  PTERM has a lot of trouble with the ANSI codes coming from
  212.             Maximus BBS software. I am working on getting this straight. It
  213.             seems Maximus uses some strange (although probably completely
  214.             legal) derivation of the cursor position command. I will get
  215.             this fixed as soon as I can get a detailed document on ANSI
  216.             emulation (and even better document on what the hell Maximus
  217.             sends out for various sequences).
  218.  
  219.  
  220.    I'm Getting Sleeeepy...
  221.    =======================
  222.  
  223.       I know, I know... Luckily, there are not many configurable options
  224.       (yet) in PTERM, so this won't take much longer.
  225.  
  226.       Currently, I have PTERM read its configuration from the environment.
  227.       The following environment variables are supported:
  228.  
  229.  
  230.          PTPORT
  231.  
  232.             Set to the integer value of the port you wish PTERM to use. I
  233.             have tested ports 1 and 2, but PTERM should be able to use any
  234.             port available (please let me know if you have problems in this
  235.             area). Example:
  236.  
  237.                set PTPORT=1
  238.  
  239.  
  240.          PTWORD
  241.  
  242.             Set to the integer value of the data word size to open the port
  243.             with. Typically 7 or 8 data bits. Example:
  244.  
  245.                set PTWORD=8
  246.  
  247.  
  248.          PTPARITY
  249.  
  250.             Set to the parity to open the port with. Supported values are:
  251.  
  252.                NONE
  253.                EVEN
  254.                ODD
  255.  
  256.             Example:
  257.  
  258.                set PTPARITY=NONE
  259.  
  260.  
  261.          PTSTOP
  262.  
  263.             Number of stop bits to open the port with. Typically 1 or 2.
  264.             Example:
  265.  
  266.                set PTSTOP=1
  267.  
  268.  
  269.          PTBAUD
  270.  
  271.             Set to the baud rate to open the port at. Supported speeds are
  272.             300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, and 115200.
  273.             PTERM locks the baud rate of the port at the speed given, as is
  274.             necessary with most modern modems.
  275.  
  276.             Example:
  277.  
  278.                set PTBAUD=38400
  279.  
  280.  
  281.          PTDOWN
  282.  
  283.             Set to the path where downloaded files are to be placed.
  284.             Example:
  285.  
  286.                set PTDOWN=e:\download
  287.  
  288.  
  289.          PTAUTOZ
  290.  
  291.             If this variable is set to ANYTHING, auto Zmodem downloads and
  292.             uploads will be enabled. To disable, make sure it is not in
  293.             defined in the environment. Example(s):
  294.  
  295.                set PTAUTOZ=yes            Enables auto Zmodem
  296.                set PTAUTOZ=               Disables auto Zmodem
  297.  
  298.  
  299.       There you have it. Those are the available options for configuring
  300.       PTERM.
  301.  
  302.       There is virtually no error checking done on configuration, so make
  303.       sure you (as in your brain) go into debug mode if you have problems.
  304.  
  305.       Included in the archive with this document and PTERM.EXE, you should
  306.       find a batch file called PT.CMD. This is the recommended method of
  307.       starting PTERM.
  308.  
  309.       Place PT.CMD and PTERM.EXE in your path. Edit PT.CMD to set the
  310.       environment variables appropriate to your system. To run PTERM, type
  311.       PT from a command prompt. The batch file will set the environment
  312.       variables, and start PTERM in its own console window. You can easily
  313.       create multiple batch files to run multiple copies of PTERM each on a
  314.       different port. This has worked for me with 2 ports simultaneously.
  315.       The batch file approach has worked from NT's CMD.EXE as well as the
  316.       4DOS for NT command interpreter replacement.
  317.  
  318.       PTERM can be placed in (and executed from) the program manager, and
  319.       even has its own embedded icon (just like a real Windows program!).
  320.       To insure that the environment is set up correctly, start the control
  321.       panel 'System' applet, and at the bottom use the two edit boxes to
  322.       appropriately define the variables described above. You will have to
  323.       log off and and back on for these to take effect, and will need to
  324.       set them for each user account.
  325.  
  326.       When using a batch enabled file transfer protocol (Zmodem), the file
  327.       selection dialog box which pops up for an upload will allow you to
  328.       select multiple files from any one directory, using the standard
  329.       Windows mouse/key combinations for multi-select lists (i.e. CTRL-CLICK
  330.       adds a file to the list, and try SHIFT-CLICK to extend the list to the
  331.       current point).
  332.  
  333.       For batch uploading, if PTERM finds a file called FILESTO.UPL in the
  334.       current directory (the directory you were in when you started PTERM),
  335.       it expects this file to contain a list of files (full paths) to
  336.       upload, and will attempt to do so. If PTERM finds this file, it will
  337.       go straight to uploading, bypassing the file selection dialog.
  338.  
  339.       I am sure I have forgotten a whole bunch of information here, but
  340.       this should be enough to get you off the ground.
  341.  
  342.  
  343.    Can I Run it Now?
  344.    =================
  345.  
  346.       Well... Ok...
  347.  
  348.       But, "Don't touch it, you'll break it..." (U.S. West T.V. ad)
  349.  
  350.       When you run PTERM, it will splat some information on the screen.
  351.       First it will display the key bindings it recognizes, things like
  352.       ALT-X to exit, PGDN to download, etc. Next, it displays the current
  353.       settings as read in from the environment. Pressing F1 will display
  354.       this information at anytime during the session.
  355.  
  356.       As mentioned, there is no dialer. This is too bad, I know, and will
  357.       be one of the first things added.
  358.  
  359.       For those of you who have been spoiled all their lives by a dialer and
  360.       do not know how to do it manually, if you have a modem which supports
  361.       the Hayes command set (are there any which don't?) you can dial a
  362.       number from PTERM like so:
  363.  
  364.          atdt555-5555               Tone dial 555-5555
  365.          atdp555-5555               Pulse dial 555-5555 (yuck!)
  366.  
  367.       On my USR Sportster, the command
  368.  
  369.          a/
  370.  
  371.       executes the last command entered, and can be used to redial.
  372.  
  373.  
  374.    Some Closing Thoughts
  375.    =====================
  376.  
  377.       Its not much, but there it is. Please let me know of any problems or
  378.       suggestions for enhancements you have.
  379.  
  380.       On my 386-33, running the March '93 beta, I have experienced excellent
  381.       transfer speeds using the Zmodem in PTERM. On text files, at 14.4K
  382.       with .v42bis (57.6K maximum), I have seen 3800+ cps. The same setup on
  383.       compressed files yields 1650 cps and higher. If you have 16550's, and
  384.       access to a FIFO enabled serial driver (I rebuilt it using the March
  385.       DDK), install it! The serial driver for NT is absolutely solid, and
  386.       extremely efficient. Before installing the FIFO enabled serial driver,
  387.       during a 1650 cps download I would experience around 1700 interrupts
  388.       per second (approx. one for each character), and during heavy
  389.       multi-tasking characters were easily dropped.
  390.  
  391.       However, after rebuilding the serial driver (the 16550 support is in
  392.       there, just not enabled -- The April update (and final retail build
  393.       when it arrives) adds the ability to enable the FIFO's through the
  394.       registry), with the same 1650 cps download I was getting around 200
  395.       interrupts per second. This makes sense since I built the serial
  396.       driver to enable the FIFO's to fire off an interrupt when they queued
  397.       8 bytes, for an 8x decrease in interrupts. Subsequently, I have never
  398.       seen PTERM drop a character in over 20 megs of file transfers.
  399.  
  400.       Another facet of the serial driver which operates well is RTS/CTS
  401.       flow control. This is always turned on when PTERM runs, later it will
  402.       be configurable. During heavy multi-tasking, RTS/CTS keeps the modem
  403.       under control, holding it off when the serial buffer gets full. This
  404.       has worked flawlessly.
  405.  
  406.       In closing, Windows NT has its problems, but all in all it is a
  407.       solid, high performance operating system for the masses. I am
  408.       confident in Microsofts (and mostly Dave Cutlers) ability to evolve
  409.       NT, so much more is yet to come (MS: thanks sooo much for the console
  410.       API, making all those UNIX utils that much easier to port!).
  411.  
  412.       Ron Cox
  413.       Paragon Consulting Group
  414.  
  415.  
  416.    Technically Speaking
  417.    ====================
  418.  
  419.       Thought you were done, didn't you? Well, if you could care less about
  420.       some of the technical details of PTERM, you are, else read on.
  421.  
  422.       As mentioned, PTERM makes full use of multi-threading. This stuff is a
  423.       trip. It can make programming much more interesting (and in many cases
  424.       greatly simplifies things!).
  425.  
  426.       There are 6 threads of execution, 5 secondary and the 1 main thread
  427.       which all Win32 applications start with.
  428.  
  429.       The first two threads of interest are in Williams communications
  430.       library. One is responsible for taking characters in from the serial
  431.       port (actually, the serial driver) and placing them in a queue created
  432.       by the library (the input queue) which is made visible to the user
  433.       code. The second takes characters from another queue and writes them
  434.       to the serial port (driver). The user code is responsible for placing
  435.       characters to be sent out the port into this output queue, and does so
  436.       through a set of 'Send' member functions.
  437.  
  438.       Also, both of Williams threads use overlapping (asynchronous) I/O,
  439.       resulting in an even more efficient set up.
  440.  
  441.       Now for the threads I spawn. They are as follows:
  442.  
  443.          o  Input thread
  444.  
  445.             Because I did not want to muck with the input queue being
  446.             managed by the communications library, I created another layer.
  447.             My input thread simply waits for characters to appear in the
  448.             main input queue, and block copies them into a local queue used
  449.             by the display thread (below). If there are no characters
  450.             waiting in the main input queue, this thread sleeps until there
  451.             is (in the discussions which follow, this thread will be
  452.             referred to as 'my input thread', to differentiate it from the
  453.             main input thread operating in the library). It may be that I
  454.             can increase PTERM's efficiency slightly by removing this layer
  455.             and having the display thread pull characters directly from the
  456.             library managed input queue -- something I will consider.
  457.  
  458.  
  459.          o  Display thread
  460.  
  461.             This thread is solely responsible for removing characters from
  462.             the local input queue (managed above) and deciding what to do
  463.             with them. For instance, if the beginning of an ANSI escape
  464.             sequence is detected this thread passes control to a function
  465.             whose job it is to interpret the sequence (note: the ANSI code
  466.             still executes within the display thread, no other thread has
  467.             been created). One of the other jobs of the display thread is
  468.             to optimize the output into the console window. This is done in
  469.             a very simplistic manner. In the absence of ANSI escape
  470.             sequences, the display thread will accumulate characters from
  471.             the local input queue into a buffer -- up to 256. When the
  472.             limit of 256 has been reached, or a special sequence is
  473.             detected, the display thread blasts the buffer to the screen in
  474.             a single call to WriteFile(). This is MUCH more efficient than
  475.             calling something like putch() for each single character.
  476.             However, at slow speeds (1200 and 2400 baud), it takes a
  477.             noticeable amount of time to accumulate 256 characters, and
  478.             this is the reason for the choppy display at these speeds. If
  479.             you set the port to anything less than 9600 baud, PTERM reduces
  480.             this 'blast' count to 64 characters, producing a smoother
  481.             display.
  482.  
  483.             As if this wasn't enough, the display thread has one more job to
  484.             perform. It watches for the tell-tale sequence of characters
  485.             which signal the host is preparing for a Zmodem upload or
  486.             download. If this sequence is found, it starts the appropriate
  487.             code.
  488.  
  489.             If there are no characters in the local input queue, the display
  490.             thread sleeps until there are.
  491.  
  492.  
  493.          o  User thread
  494.  
  495.             The user threads job is pretty easy. If the user hits a key,
  496.             decide what to do with it. Typically the key will be sent right
  497.             out the port. If it is a control key sequence (like ALT-X), then
  498.             the user thread executes the code appropriate for that key. This
  499.             thread blocks on the keyboard, and as such sleeps when there are
  500.             no characters available.
  501.  
  502.  
  503.          o  Main thread
  504.  
  505.             The main thread is the first thread which executes (starting in
  506.             main()). It initializes the port and other things, starts up the
  507.             three threads above, and then goes to sleep waiting for all
  508.             three of the threads above to terminate. At this point it wakes
  509.             up and calls ExitProcess(), ending PTERM.
  510.  
  511.  
  512.       Them's the threads, and a nice bunch of threads they are. However, if
  513.       there is one thing I quickly learned from spawning threads all over
  514.       the place, its that synchronization thingy.
  515.  
  516.       Here's the scenario: My input thread pulls characters from the main
  517.       input queue to place in the local input queue. Fair enough. So, I
  518.       start a Zmodem download. Boom! Of course, the Zmodem download code
  519.       also wants to pull characters from the main input queue, so my thread
  520.       fights with the Zmodem code. Remember, the Zmodem code is run as part
  521.       of the display thread. So my input thread grabs some characters, then
  522.       the Zmodem code [running in the display thread] grabs some
  523.       characters, and so on. Zmodem will end up missing a bunch of
  524.       characters it expected to see, and my input thread grab some
  525.       characters from the transfer which the display thread will finally
  526.       get and try to display. A mess...
  527.  
  528.       So, I need to find a way to synchronize the two threads. When Zmodem
  529.       wants control of the main input queue, it needs to 'ask' for control
  530.       from my input thread. Well, it really isn't as formal as all that.
  531.  
  532.       Just before my input thread grabs characters from the main input
  533.       queue, it waits on a semaphore. Simplified, a semaphore is just an
  534.       object which keeps count of how many threads have asked for control
  535.       of it. When its count is 0, access is granted to the waiting thread.
  536.       When a thread gets access to it, the semaphores count is incremented.
  537.       Any other thread which waits on it goes to sleep until the semaphores
  538.       count becomes 0 again. The count is decremented when a thread
  539.       explicitly releases a semaphore, thus allowing another thread to gain
  540.       access (this can get complicated when there are more than 2 threads).
  541.  
  542.       Ok, where were we? Oh, yes, my input thread waits on this semaphore
  543.       gadget. Typically, it gets control instantly and drops into the main
  544.       body of its code where it grabs characters from the main input queue
  545.       and stuffs them in the local queue the display thread uses. Once it
  546.       has transferred some characters, it releases the semaphore (and gives
  547.       up the rest of its time slice). Its during the time between releasing
  548.       the semaphore and waiting on it again that the file transfer code
  549.       must act.
  550.  
  551.       The first line of code for a file transfer waits on the same
  552.       semaphore. As soon as my input thread releases the semaphore, the file
  553.       transfer code gets and holds access to it until the transfer is
  554.       completed, thus preventing my input thread from mucking with the main
  555.       input queue during the transfer. Whew!
  556.  
  557.       Being this is my first foray into threads, I am very interested to
  558.       find out if my code breaks on a multi-processor machine. Does my code
  559.       work now because it takes advantage of the synchronous behavior of a
  560.       single processor? Interesting stuff, but I forgot to pick up my
  561.       Sequent 16 processor monster-box at the grocery store the other day,
  562.       so I suppose the answer will have to wait...
  563.  
  564.       I found one other interesting thing about Windows NT -- it seems to
  565.       like to write data to the disk right away. Generally, this is a good
  566.       thing, keeps your data safe. However, with Zmodem code writing 1K
  567.       blocks to disk every .7 seconds or so (at 1650 cps), the disk access
  568.       began to affect the performance of the download. The solution was
  569.       easy, I just used a call to setvbuf() to create a memory buffer. The
  570.       size I chose is 64K. So the system (C runtime) will accumulate 64K
  571.       bytes from the fwrite()'s before writing to disk. Believe it or not,
  572.       NT can actually write a 64K block to disk as quickly as a 1K block --
  573.       difference is, now Zmodem only hits the disk one a minute or so (at
  574.       1650 cps). Works great. Notice I said I made a 64K buffer. You 16 bit
  575.       guys probably have (as I did) the signed integer maximum value
  576.       memorized, 32K right? Well, under NT, a signed integer is 2^31, for a
  577.       maximum [signed] value of 2 GB. So 64K was small compared to what
  578.       I could make it.
  579.  
  580.       The file access areas of the transfer protocols are excellent
  581.       candidates for overlapped I/O, probably doing away with the need for a
  582.       write buffer. However, since Williams library is meant to be
  583.       multi-platform, it is best to keep it as generic as possible. But,
  584.       it is C++, and with proper inheritance the function responsible for
  585.       writing data to disk could be overloaded (and William has isolated
  586.       this operation for easy overloading!). A possible future enhancement
  587.       to PTERM.
  588.  
  589.       One more technical note: PTERM does not change its base priority
  590.       class, but it does manipulate the priority of several of its threads
  591.       relative to the priority class it is started at. What? Ok, if you run
  592.       PTERM from the command line like so:
  593.  
  594.          start pterm.exe
  595.  
  596.       then PTERM gets a base priority class of NORMAL. Using these commands:
  597.  
  598.          start /high pterm.exe
  599.          start /realtime pterm.exe
  600.  
  601.       starts PTERM with a base priority class of HIGH or REALTIME
  602.       respectively.
  603.  
  604.       Whats interesting is that when I started work on PTERM, I assumed I
  605.       would need to have PTERM boost its base priority class to at least
  606.       HIGH to make sure it could respond quick enough to bytes coming in
  607.       over the port at high baud rates. This resulted in poor performance
  608.       (dropping characters and such). So I assumed PTERM wasn't getting the
  609.       priority necessary to keep up with bytes coming in the port. So, I
  610.       pumped the base priority class up to REALTIME. The performance was
  611.       even worse!
  612.  
  613.       Suddenly, it began to make sense. This is what I figure is happening:
  614.       The serial driver itself probably runs at the upper end of NORMAL
  615.       priority, or maybe even the lower end of HIGH priority. So I figure
  616.       when I boosted the priority of PTERM to the same or above the priority
  617.       of the serial driver, PTERM was stealing away time from the serial
  618.       driver, causing the driver itself to drop characters!
  619.  
  620.       This is pure speculation, since I have no detailed knowledge of what
  621.       priority the serial driver runs at. I assume there is a small part of
  622.       the serial driver which is interrupt driven, and depending on the
  623.       interrupt level it runs at, it can be preempted by other processes.
  624.       I further assume that some other piece of the serial driver gets
  625.       scheduled by the interrupt driven part above to remove characters from
  626.       some small local buffer and place them in the buffer which ReadFile()
  627.       uses. Again, this is pure speculation.
  628.  
  629.       At any rate, the interesting part is that when I changed PTERM to NOT
  630.       change its base priority class, so that upon starting PTERM, it would
  631.       default to the NORMAL priority class, performance was MUCH better!
  632.  
  633.       What does this tell me? The NT serial driver is incredibly efficient,
  634.       yet can become sensitive to other high priority processes in the
  635.       system (the behavior I described above was on my 386-33 -- this may not
  636.       be an issue on faster machines, where higher priority processes might
  637.       not have such adverse affects on the serial driver because the faster
  638.       processor is able to juggle all the processes more efficiently).
  639.  
  640.       At any rate, what it means to you the user is that you are free to
  641.       start PTERM at any of the 4 base priority classes, and your mileage
  642.       may vary. Examples:
  643.  
  644.          start /idle pterm.exe
  645.          start /normal pterm.exe
  646.          start /high pterm.exe
  647.          start /realtime pterm.exe
  648.  
  649.       I strongly recommend leaving it at NORMAL priority (by using the
  650.       /normal switch, or not giving a priority at all). You are, of course,
  651.       free to experiment.
  652.  
  653.       Well, the rest of PTERM is plain and boring (as if the preceding was
  654.       not!). So not much else to say. Any specific questions? Feel free to
  655.       contact me!
  656.